Напомним, что технология FLEX позволяет запускать виртуальные ПК VMware Horizon View локально (как на Mac во Fusion, так и на Windows в Workstation Player), без требования наличия связи с датацентром компании.
Этот документ посвящен тому, как необходимо анализировать, планировать и строить архитектуру инфраструктуры VDI (Virtual Desktop Infrastructure), которая будет стандартизирована по составу, унифицированно управляться, легко масштабироваться и быстро реагировать на изменения, которые рождают требования бизнеса. Звучит булшитово, но зато фундаментально.
Вот как авторы документа представляют себе основные фазы внедрения инфраструктуры виртуальных десктопов на предприятии:
1. Определение основных драйверов бизнеса компании и вариантов использования VDI.
2. Определение сервисов, которые будут доставляться пользователям.
3. Выработка архитектурных принципов и общей концепции построения решения.
4. Подготовка компонентной архитектуры VMware Horizon 7 Enterprise.
5. Планирование развертывания платформы VMware vSphere 6.
6. Планирование физической инфраструктуры и определение состава оборудования.
7. Планирование интеграции сервисов между собой.
8. Планирование взаимодействия пользователей с сервисами через интерфейсы VDI.
В документ включены так называемые Service Blueprints, которые позволяют понять эталонную архитектуру необходимых сервисов в среде виртуальных ПК:
Из документа многим будет полезно узнать и о средстве VMware Identity Manager, которое предоставляет точку входа пользователям компании и реализует рабочее пространство назначенных пользователю десктопов и приложений:
То есть, по-сути, документ представляет собой референсную архитектуру и методологию построения VDI-инфраструктуры, которую можно адаптировать для большинства сценариев корпоративной инфраструктуры. Скачать документ можно по этой ссылке.
Не так давно компания VMware выпустила интересный и полезный документ, который пригодится очень многим Enterprise-администраторам виртуальной инфраструктуры - "Oracle Databases on VMware Best Practices Guide".
Как и остальные документы серии Best Practices Guide, данный документ предоставляет вполне конкретные рекомендации и лучшие практики по эксплуатации СУБД Oracle на платформе VMware vSphere.
Основные разделы документа:
VMware Support for Oracle Databases on vSphere - рассказывает о политиках поддержки СУБД Oracle на платформе vSphere.
Server Guidelines - рекомендации по выбору и конфигурации серверов.
Virtual CPU Guidelines - как правильно сайзить виртуальные процессоры ВМ.
Memory Guidelines - лучшие практики по использованию оперативной памяти (что очень важно для баз данных).
Storage Guidelines - как правильно выбирать тип хрананилища, настраивать его и правильно эксплуатировать (в том числе Virtual SAN).
Networking Guidelines - лучшие практики по конфигурации сетевого взаимодействия (виртуальные коммутаторы, сетевые адаптеры и т.п.).
Guest Operating System Guidelines - как правильно настроить гостевую ОС, чтобы база данных работала быстро.
Database Guidelines - общие принципы правильной архитектуры решений Oracle на платформе vSphere.
ESXTOP/rESXTOP - средства мониторинга производительности серверов.
Backup and Recovery - резервное копирование и восстановление, а также защита данных.
High Availability - обеспечение высокой доступности и средства отказоустойчивости.
Disaster Recovery - восстановление после масштабных сбоев с помощью решений vSphere Replication, SRM и прочих.
VMware Engineered Systems - использование готовых референсных архитектур (например, EVO:RAIL) для организации больших инфраструктур.
Скачать "Oracle Databases on VMware Best Practices Guide" можно по этой ссылке.
Компания StarWind Software, выпускающая лучший продукт Virtual SAN для создания отказоустойчивых хранилищ под виртуализацию VMware и Microsoft, выпустила интересный документ "StarWind Storage Appliance Overview".
StarWind Storage Appliance - это готовый к развертыванию инфраструктуры хранилищ для гипервизоров VMware ESXi и Microsoft Hyper-V программно-аппаратный комплекс, который можно просто масштабировать по емкости путем приобретения новых узлов, при этом обеспечивается отказоустойчивость всей подсистемы хранения:
Более подробно о таких функциях StarWind Storage Appliance, как файловая система Log-Structured File System (LSFS), серверное кэширование, дедупликация, компрессия данных при передаче, асинхронная репликация и многое другое, вы можете прочитать в документе, а также по этой ссылке.
Компания VMware выпустила весьма полезный документ "VMware Virtual SAN 6.2
Network Design Guide", в котором приведены конкретные рекомендации по настройке и конфигурации сети при организации отказоустойчивых кластеров хранилищ.
Посмотрим, какие интересные моменты есть в документе. Например, рассматривается следующая архитектура построения кластера Virtual SAN (это Leaf-Spine архитектура):
В такой сети показатель переподписки (oversubscription) между стойками равен 4:1 (от хостов идет 16 линков по 10 Гбит к свичу, от которого идет 4 линка по 10 Гбит к Spine-коммутатору). В этом случае, если предположить, что на хостах 10 ТБ емкости, из которых 6 ТБ занимают данные виртуальных машин, и вдруг возникнет необходимость операции rebuild для кластера (при FTT=1), то при использовании 3/4 пропускной способности канала (то есть 30 Гбит/с) операция займет 26 минут. Если же объем данных на хосте увеличить до 12 ТБ, а канал уменьшить до 10 Гбит/с, то rebuild займет 156 минут. Мораль такова - нельзя перебарщивать с переподпиской, а также нужно обеспечить широкий канал между узлами кластера.
Еще из рекомендаций в документе:
Отключите Flow Control на физическом оборудовании, у Virtual SAN есть свой механизм контроля перегрузки канала.
Используйте vSphere Distributed Switch (VDS) совместно с Virtual SAN.
Настройте Load Based Teaming (LBT), который балансирует нагрузку, в зависимости от загрузки физического адаптера (похоже на Virtual Port ID, только привязка к порту пересматривается каждые 30 секунд).
Если используете несколько кластеров Virtual SAN - помещайте трафик каждого из них в отдельный VLAN.
Если в датацентре используются большие кадры jumbo frames - используйте их в кластере Virtual SAN, но если не используются - то отдельно включать их не надо.
Включите Cisco Discovery Protocol (CDP) и Link Layer Discovery
Protocol (LLDP) в режимах и приема, и передачи.
В документе присутствует еще несколько интересных рекомендаций, прочитать которые будет особенно интересно администраторам крупных инфраструктур и больших кластеров Virtual SAN.
Напомним основные стадии жизненного цикла продуктов VMware:
Genetral Availability - официальная доступность продукта для загрузки, с даты которой начинается General Support Phase.
General Support Phase - эта фаза начинается после выпуска мажорного релиза (GA) и длится определенное время. В этот период пользователи, купившие официальную поддержку VMware (а не купить ее нельзя) получают апдейты и апгрейды, багофиксы и фиксы безопасности, а также техническое сопровождение в соответствии с Terms and Conditions.
Technical Guidance Phase - эта фаза (если она доступна) начинается с момента окончания предыдущей фазы и длится заданное время. Здесь уже предоставляются инструкции через портал самообслуживания, а по телефону звонки не принимаются. В этой фазе можно открыть кейс в техподдержке онлайн, но только для поддерживаемых конфигураций. В этой фазе VMware не оказывает поддержки, касающейся оборудования, обновлений ОС, патчей безопасности или багофиксов (если о другом не объявлено дополнительно). Предполагается, что в этой фазе пользователи используют стабильные версии ПО и конфигураций при нормальных (не повышенных) нагрузках.
End of Support Life (EOSL) - в этой фазе продукт уже не поддерживается VMware. Это означает окончание первых двух фаз. Кроме этого, здесь происходит прекращение продаж продукта.
End of Availability (EOA) / End Of Distribution (EOD) - в этом режиме продукт уже не поддерживается, и он недоступен на сайте VMware, то есть его, попросту говоря, нельзя скачать.
Компания VMware выпустила очень интересный документ "VMware vSphere 6
Fault Tolerance
Architecture and Performance", посвященный производительности технологии VMware Fault Tolerance (FT), которая позволяет обеспечивать непрерывную доступность виртуальных машин, даже в случае отказа хост-сервера VMware ESXi. Делается это за счет техники Fast Checkpointing, по своей сути похожей на комбинацию Storage vMotion и vMotion, которая копирует состояние дисков, памяти, процессорных команд и сетевого трафика на резервную машину, поддерживая ее в полностью синхронизированном с первой состоянии. На данный момент vSphere 6 FT поддерживает виртуальные машины с конфигурацией до 4 vCPU и до 64 ГБ оперативной памяти на хост ESXi.
Давайте посмотрим на интереснейшие результаты тестирования производительности, приведенные в документе.
1. Процедура компиляции ядра в гостевой ОС.
Эта процедура грузит CPU на 100%, поэтому посмотрим, каковы тут потери, связанные с аспектами производительности процессора и синхронной передачи команд. Все вполне хорошо, потери небольшие:
2. Сетевая активность.
Если говорить о производительности сетевой коммуникации, то на получение данных потерь практически нет, а вот на передачу все происходит процентов на 10 медленнее. Результат для 1 Гбит сети:
Кстати, очевидно, что сетевой трафик именно самой сети FT максимальный, когда машина принимает много данных (их нужно синхронизировать на второй узел), когда же данные передаются там трафик намного меньше (машина их просто отдает, а синхронизировать нужно только сам процесс передачи и параметры канала).
Результат для 10 Гбит сети. Вот тут и происходит ситуация, когда канал на прием забивается FT-трафиком, как итог - прием происходит только на полосе 2,4 Гбит:
Из-за необходимости поддержки параметров сетевой передачи и приема в синхронном режиме возникает Latency около 6 миллисекунд:
3. Тестирование подсистемы ввода-вывода.
Для тестирования работы с хранилищами (I/O) взяли стандартный инструмент IOMeter. Особых потерь не обнаружилось:
4. Тест Swingbench для Oracle 11g.
Для теста была взята OLTP-нагрузка на базу данных. По числу транзакций в секунду потери небольшие, но задержка по времени ответа возникает значительная:
5. Тест DVD Store на Microsoft SQL Server 2012.
Здесь была запущена симуляция 64 пользовательских сессий. По-сути, этот тест очень похож на методику для Oracle, ну и результаты здесь также соответствующие (но по времени отклика как-то все очень печально):
6. Бенчмарк на базе TPC-E.
Здесь были симулированы операции сервера брокерской компании, который производит обработку OLTP-транзакций в реальном времени. Тест очень стрессовый, и потери здесь весьма существенны:
7. Операции VMware vCenter Server.
Ну а здесь уже сам сервер vCenter защитили технологией Fault Tolerance и измерили производительность операций для двух типов нагрузки - легкой и тяжелой. При тяжелой нагрузке все происходит медленнее больше чем в 2 раза:
vSphere Web Client работает, в общем-то, неплохо, но хотелось бы лучше:
Результаты тестирования очень полезны - теперь администраторы смогут закладывать потери производительности на поддержание FT-кластера в архитектуру планируемой инфраструктуры для бизнес-критичных приложений.
Когда вы ставите один сервер VMware ESXi, то проще всего сделать это, смонтировав ISO-образ через iLO или подобную консоль, либо воткнув загрузочную флешку непосредственно в сервер. Но если у вас несколько хост-серверов ESXi, то делать так уже несолидно для опытного администратора. В целях ускорения процесса он использует процедуру загрузки установщика хоста по сети через механизм PXE, а самые крутые администраторы уже используют средство Auto Deploy, у которого сравнительно недавно появился GUI.
На эту тему компания VMware выпустила очень полезный документ "Installing ESXi Using PXE", в котором эта процедура расписывается по шагам (как для BIOS, так и для UEFI-хостов):
Интересна диаграмма зрелости процесса установки VMware ESXi в организации. Новички прожигают исошку на диск, а крутые перцы - используют Auto Deploy для stateless-хостов:
А вот, например, основная диаграмма последовательности процессов при установке ESXi через PXE:
По шагам процедура выглядит так:
1. Администратор загружает целевой хост ESXi.
2. Этот хост делает DHCP-запрос.
3. DHCP-сервер отвечает с IP-параметрами и расположением TFTP-сервера, который содержит загрузчик.
4. ESXi обращается к серверу TFTP и запрашивает файл загрузчика, который указал DHCP-сервер.
5. TFTP-сервер посылает загрузчик хосту ESXi, который исполняет его. Начальный загрузчик догружает дополнительные компоненты с TFTP-сервера.
6. Загрузчик ищет конфигурационный файл на TFTP-сервере, скачивает ядро и другие компоненты ESXi с HTTP-сервера, который размещен на TFTP-сервере, и запускает ядро на хосте ESXi.
7. Установщик ESXi запускается в интерактивном режиме, либо используя kickstart-скрипт, который указан в конфигурационном файле.
Для автоматизации задач по подготовке ISO-образа ESXi к загрузке через PXE вы можете использовать вот этот полезный скрипт.
Таги: VMware, ESXi, PXE, Boot, Auto Deploy, Whitepaper, vSphere
Какое-то время назад мы писали о технологии доставки приложений пользователям инфраструктуры настольных ПК предприятия - VMware App Volumes (ранее это называлось Cloud Volumes). Суть ее заключается в том, что виртуализованные и готовые к использованию приложения VMware ThinApp доставляются пользователям в виде подключаемых виртуальных дисков к машинам.
Недавно компания VMware выпустила документ "VMware App Volumes Reference Architecture", в котором объясняется работа технологии App Volumes, рассматривается референсная архитектура этого решения, а также проводится тестирование производительности доставляемых таким образом приложений по сравнению с их нативной установкой внутри виртуальных ПК:
Собственно, типовая архитектура решения App Volumes выглядит следующим образом:
Здесь показаны основные компоненты такой инфраструктуры:
AppStacks - это тома, которые содержат сами установленные приложения и работают в режиме Read Only. Их можно назначить пользователям Active Directory, группам или OU. Один такой диск может быть назначен сразу нескольким виртуальным ПК (по умолчанию доступен всем машинам датацентра).
Writable Volumes - это персонализированные тома, которые принадлежат пользователям. Они хранят настройки приложений, лицензионную информацию, файлы конфигураций приложений и сами приложения, которые пользователь установил самостоятельно. Один такой диск может быть назначен только одному десктопу, но его можно перемещать между десктопами.
App Volumes Manager Server - это Windows-сервер, содержащий административную консоль для настройки продукта и управления им.
В качестве референсной архитектуры используется инфраструктура из 2000 виртуальных ПК, запущенных на 18 хостах ESXi инфраструктуры VMware Horizon View:
Для генерации нагрузки использовались различные сценарии пользовательского поведения, создаваемые с помощью средства Login VSI, ставшего уже стандартом де-факто для тестирования VDI-инфраструктур, развернутого на трех хост-серверах.
Здесь описаны 3 варианта тестирования:
Приложения, нативно установленные в виртуальных ПК.
Приложения App Volumes, использующие один AppStack, содержащий основные приложения пользователей.
Приложения App Volumes, распределенные по трем различным AppStack.
Для обоих случаев тестирования App Volumes использовался один Writable Volume. Тут были получены следующие результаты (больше очков - это лучше).
Посмотрим на время логина пользователей при увеличении числа одновременных сессий в референсной архитектуре:
Взглянем на время отклика приложений:
Оценим время запуска приложений:
В целом-то, нельзя сказать, что потери производительности незначительные - они, безусловно, чувствуются. Но радует, что они фиксированы и хорошо масштабируются при увеличении числа одновременных сессий в VDI-инфраструктуре.
Документ очень полезен для оценки потерь производительности с точки зрения User Experience при использовании App Volumes по сравнению с традиционной доставкой приложений. Скачать 50-страничный документ можно скачать по этой ссылке - почитайте, там действительно интересно все изложено.
Те из вас, кто использовал решение для обеспечения высокой доступности хранилищ под виртуализацию StarWind Virtual SAN, знают, что в продукте предусмотрена возможность асинхронной репликации данных на резервный узел для обеспечения катастрофоустойчивости. В этом случае на резервную площадку откидывается снапшот данных основного узла по заданному администратором расписанию.
В документе приведены как общие сведения об устройстве механизма асинхронной репликации данных StarWind Virtual SAN, так и подробные пошаговые инструкции по его настройке. Также советуем посмотреть еще один документ StarWind об асинхронной репликации.
Для тех из вас, кто использует в производственной среде или тестирует решение VMware NSX для виртуализации сетей своего датацентра, компания VMware подготовила полезный документ "VMware NSX for vSphere Network Virtualization Design Guide", который вышел уже аж в третьей редакции.
Документ представляет собой рефернсный дизайн инфраструктуры виртуализации сетей в датацентре и описывает архитектуру решения NSX на физическом и логическом уровнях.
В новой версии документа появилась следующая информация для сетевых архитекторов:
сайзинг решения NSX для небольших датацентров
лучшие практики маршрутизации
микросегментация и архитектура компонента обеспечения безопасности среды Service Composer
Документ содержит ни много ни мало 167 страниц. Скачать его можно по этой ссылке.
На блогах VMware появился интересный пост про производительность виртуальных машин, которые "растянуты" по ресурсам на весь физический сервер, на котором они запущены. В частности, в посте речь идет о сервере баз данных, от которого требуется максимальная производительность в числе транзакций в секунду (см. наш похожий пост о производительности облачного MS SQL здесь).
В данном случае речь идет о виртуализации БД с типом нагрузки OLTP, то есть обработка небольших транзакций в реальном времени. Для тестирования использовался профиль Order-Entry, который основан на базе бенчмарка TPC-C. Результаты подробно описаны в открытом документе "Virtualizing Performance Critical Database Applications in VMware vSphere 6.0", а здесь мы приведем основные выдержки.
Сводная таблица потерь на виртуализацию:
Метрика
Нативное исполнение нагрузки
Виртуальная машина
Пропускная способность транзакций в секунду
66.5K
59.5K
Средняя загрузка логических процессоров (72 штуки)
84.7%
85.1%
Число операций ввода-вывода (Disk IOPS)
173K
155K
Пропускная способность ввода-вывода дисковой подсистемы (Disk Megabytes/second)
929MB/s
831MB/s
Передача пакетов по сети в секунду
71K/s receive
71K/s send
63K/s receive
64K/s send
Пропускная способность сети в секунду
15MB/s receive
36MB/s send
13MB/s receive
32MB/s send
А вот так выглядит график итогового тестирования (кликабельно):
Для платформы VMware ESXi 5.1 сравнивалась производительность на процессоре микроархитектуры Westmere, а для ESXi 6.0 - на процессорах Haswell.
Результаты, выраженные в числе транзакций в секунду, вы видите на картинке. Интересно заметить, что ESXi версии 6.0 всерьез прибавил по сравнению с прошлой версией в плане уменьшения потерь на накладные расходы на виртуализацию.
А вот так выглядят усредненные значения для версий ESXi в сравнении друг с другом по отношению к запуску нагрузки на нативной платформе:
Ну и несложно догадаться, что исследуемая база данных - это Oracle. Остальное читайте в интереснейшем документе.
Компания VMware выпустила очень познавательный документ "An overview of VMware Virtual SAN caching algorithms", который может оказаться полезным всем тем, кто интересуется решением для создания программных хранилищ под виртуальные машины - VMware Virtual SAN. В документе описан механизм работы кэширования, который опирается на производительные SSD-диски в гибридной конфигурации серверов ESXi (то есть, SSD+HDD).
SSD-диски используются как Performance tier для каждой дисковой группы, то есть как ярус производительности, который преимущественно предназначен для обеспечения работы механизма кэширования на чтение (Read cache, RC). По умолчанию для этих целей используется 70% емкости SSD-накопителей, что экспериментально было определено компанией VMware как оптимальное соотношение.
SSD-диски значительно более производительны в плане IOPS (тысячи и десятки тысяч операций в секунду), поэтому их удобно использовать для кэширования. Это выгодно и с экономической точки зрения (доллары на IOPS), об этом в документе есть наглядная табличка:
То есть, вы можете купить диск SSD Intel S3700 на 100 ГБ за $200, который может выдавать до 45 000 IOPS, а это где-то $0,004 за IOPS. С другой же стороны, можно купить за те же $200 диск от Seagate на 1 ТБ, который будет выдавать всего 100 IOPS, что составит $2 на один IOPS.
Кэш на чтение (RC) логически разделен на "cache lines" емкостью 1 МБ. Это такая единица информации при работе с кэшем - именно такой минимальный объем на чтение и резервирование данных в памяти используется. Эта цифра была высчитана экспериментальным путем в исследовании нагрузок на дисковую подсистему в реальном мире, которое VMware предпочитает не раскрывать. Кстати, такой же величины объем блока в файловой системе VMFS 5.x.
Помимо обслуживания кэша на SSD, сервер VMware ESXi использует небольшой объем оперативной памяти (RAM) для поддержки горячего кэша обслуживания этих самых cache lines. Он содержит несколько самых последних использованных cache lines, а его объем зависит от доступной памяти в системе.
Также в памяти хранятся некоторые метаданные, включая логические адреса cache lines, валидные и невалидные регионы кэша, информация о сроке хранения данных в кэше и прочее. Все эти данные постоянно хранятся в памяти в сжатом виде и никогда не попадают в своп. При перезагрузке или выключении/включении хоста кэш нужно прогревать заново.
Итак, как именно работает кэширование на SSD в VMware Virtual SAN:
1. Когда операция чтения приходит к Virtual SAN, сразу же включается механизм определения того, находятся ли соответствующие данные в кэше или нет. При этом запрашиваемые данные за одну операцию могут быть больше одной cache line.
2. Если данные или их часть не находятся в RC, то для них резервируется буфер нужного объема с гранулярностью 1 МБ (под нужное количество cache lines).
3. Новые аллоцированные cache lines вытесняют из кэша старые в соответствии с алгоритмом Adaptive Replacement Cache (ARC), который был лицензирован VMware у IBM.
4. В случае промаха кэша каждое чтение одной cache line с HDD разбивается на чанки размером 64 КБ (этот размер тоже был определен экспериментально в ходе исследований). Это сделано для того, чтобы не забивать очередь на чтение с HDD "жирной" операцией чтения в 1 МБ, которая бы затормозила общий процесс ввода-вывода на диск.
5. В общем случае, одна операция чтения запрашивает лишь часть данных одной cache line, а первыми читаются именно нужные 64 КБ чанки с HDD-диска от этой cache line.
6. Запрошенные с HDD-диска данные сразу отдаются к подсистеме вывода и направляются туда, откуда их запросили, а уже потом в асинхронном режиме они попадают в соответствующие cache lines кэша и под каждую из них выделяется буфер 1 МБ в памяти. Таким образом устраняются потенциальные затыки в производительности.
В документе описаны также и механики работы кэша на запись (Write cache), для которого используется техника write-back, а также рассматриваются All Flash конфигурации. Читайте - это интересно!
Как и другие документы этой серии, этот whitepaper богат различными графиками и диаграммами, касающимися производительности решения. Например, вот производительность обычного кластера VMware Virtual SAN 6.1 и растянутого с задержками (latency) в 1 мс и 5 мс:
Основные моменты, раскрываемые в документе:
Развертывание и настройка Virtual SAN Stretched Cluster
Производительность растянутого кластера в сравнении с обычным
Производительность кластера при различных отказах (хост, сайт целиком)
Лучшие практики использования растянутых кластеров
Основные сведения, которые можно почерпнуть из небольшого 22-страничного документа:
варианты использования решения SRM
основные топологии при построении архитектуры (active/active, active/passive и т.д.)
развертывание и настройка продукта
возможности механизма репликации
сведения о настройке Protection Groups
настройка и использование планов аварийного восстановления (Recovery Plans)
рабочие процессы по тестированию аварийного восстановления, собственно аварийному восстановлению (Failover), а также возврату рабочей инфраструктуры с резервной на основную (Failback)
vCenter Server 6.0 имеет существенно большую производительность, чем предыдущая версия vCenter Server 5.5. Некоторые операции исполняются почти в 2 раза быстрее, а отображение страниц в Web Client работает на 90% быстрее.
vCenter Server Appliance работает почти так же быстро, как и полноценный vCenter Server для Windows.
Ресурсы, выделенные для vCenter (CPU, память, диск и полоса пропускания сети) влияют на размер доступного в vCenter окружения и скорость исполнения операций.
Используя рекомендации из документа и правильно выделяя ресурсы в зависимости от нагрузки, пользователи могут значительно повысить производительность стандартной конфигурации VMware vCenter.
Совсем недавно компания VMware выпустила интересный документ о производительности операций виртуальной инфраструктуры под управлением VMware vCenter 6 для серверов, работающих в кластере HA/DRS - "VMware vCenter Server 6.0 Cluster Performance".
Упор сделан на сравнение производительности свежей версии vCenter 6.0 с предшественником - vCenter 5.5. Напомним, что шестая версия поддерживает до 64 хоста ESXi в кластере и до 8000 виртуальных машин (до этого было 32 хоста ESXi и 3000 виртуальных машин).
Конфигурация тестовой среды была следующей:
Программные компоненты:
Производительность каких операций проверялась:
Add Port Group
Remove Port Group
Clone VM
Create Folder
Delete Folder
Create Snapshot
Delete Snapshot
Group Power-On VMs
vMotion VM
Power On VM
Power Off VM
Reconfigure VM
Register VM
Unregister VM
Relocate VM
Remove VM
Reset VM
Suspend VM
Resume VM
В результате тестирования были получены следующие результаты:
vCenter 6.0 показывает лучшую операционную производительность (в количестве операций) до 66% лучше прошлой версии.
Улучшенная производительность под очень тяжелыми нагрузками.
Одинаковая производительность как vCenter Server для Windows, так и виртуального модуля vCSA на базе Linux.
Операции с виртуальными машинами происходят существенно быстрее.
Больше интересных подробностей и графиков вы можете найти в документе.
Компания StarWind, известная своим продуктом StarWind Virtual SAN для создания программных отказоустойчивых хранилищ, выпустила интересный документ о своей журналируемой файловой системе - "LSFS container technical description".
Напомним, что файловая система LSFS изначально работает с большими блоками данных, что положительно сказывается на сроке службы флеш-накопителей (SSD), на которых размещаются виртуальные машины. Файловая система LSFS преобразовывает small random writes в большие последовательные операции записи, что также существенно увеличивает производительность.
Помимо этого, LSFS имеет следующие полезные функции:
встроенная поддержка снапшотов и точек восстановления хранилищ (автоматически они делаются каждые 5 минут)
поддержка непрерывной дефрагментации (она идет в фоне)
дедупликация данных "на лету" (то есть, перед записью на диск)
улучшения производительности за счет комбинирования операций записи
поддержка overprovisioning
использование технологии снапшотов и техник отслеживания изменений при синхронизации HA-узлов
Многие из вас знают о решении StarWind Virtual SAN, предназначенном для создания отказоустойчивых хранилищ. Но не все в курсе, что у StarWind есть виртуальный модуль Virtual SAN OVF (ссылка на его загрузку высылается по почте), который представляет собой шаблон виртуальной машины в формате OVF готовый к развертыванию на платформе VMware vSphere.
Недавно компания StarWind выпустила документ Virtual SAN OVF Deployment Guide, в котором описана процедура развертывания данного виртуального модуля.
Поскольку Microsoft на уровне лицензии запрещает распространение таких виртуальных модулей с гостевой ОС Windows в формате виртуальных дисков VMDK, придется сделать несколько дополнительных операций по развертыванию, а именно:
1. Запустить StarWind V2V Converter.
2. Преобразовать VHDX-диски в формат VMDK.
3. Поместить VMDK и OVF в одну папку.
4. Развернуть OVF на сервере VMware ESXi.
5. Заполнить поля IP-адреса для включения машины в виртуальную сеть.
6. Подождать окончания процесса создания и конфигурации виртуальной машины.
Больше подробностей о виртуальном модуле StarWind Virtual SAN OVF вы найдете в документе.
Таги: StarWind, Whitepaper, Virtual Appliance, OVF, Storage, HA
Не так давно компания VMware выпустила интересный документ "VMware Virtual SAN 6.0 Proof of Concept Guide", который позволяет представить себе в голове план пошаговой имплементации решения VSAN во всех его аспектах (хосты ESXi, настройка сети, тестирование решения, производительность, средства управления и т.п.).
Процесс, описанный в документе, представляет собой развертывание кластера Virtual SAN в изолированной среде для целей тестирования, чтобы обкатать решение в небольшой инфраструктуре и потом уже отправить его в производственную среду.
Основные разделы документа освещают следующие темы:
Подготовительные работы
Настройка сетевого взаимодействия
Включение функций кластера хранилищ
Функциональность платформы VMware vSphere при операциях в кластере VSAN
Симуляция аппаратных отказов и тестирование поведения кластера
Управление кластером Virtual SAN
Сам документ содержит 170 страниц и представляет собой ну очень детальное руководство по развертыванию кластера Virtual SAN и его тестированию. Причитав его, вы поймете множество интересных технических особенностей, касающихся принципов работы решения.
Скачать "VMware Virtual SAN 6.0 Proof of Concept Guide" можно по этой ссылке.
Недавно компания VMware выпустила очень интересный документ "What’s New in VMware vSphere 6 - Performance", в котором рассказывается о том, какие улучшения были сделаны в новой версии vSphere 6.0, касающиеся различных аспектов производительности платформы (вычислительные ресурсы, хранилища и сети).
Документ выпущен отделом технического маркетинга VMware, и в нем приведены вполне конкретные сведения об увеличении производительности компонентов vSphere.
Например, вот сводная картинка улучшения производительности vCenter (версия 6.0 против 5.5) при тяжелых нагрузках на Microsoft SQL Server 2012 в зависимости от числа объектов, которые находятся под управлением сервиса (размер Inventory). Данные приведены в количестве операций в минуту. Результаты впечатляют:
Улучшения кластеров отказоустойчивых хранилищ VMware Virtual SAN (результаты по конфигурации All-Flash еще не обработаны):
С точки зрения производительности виртуальных сетевых адаптеров VMXNET 3, платформа vSphere 6.0 научилась выжимать из них более 35 гигабит в секунду при работе с физическими адаптерами 40 GbE:
Ну и в целом в документе есть еще много чего интересного - скачивайте.
Мы уже писали про издание технического характера VMware Technical Journal (VMTJ), которое представляет собой периодический журнал о различного рода проблемах, которые рассматриваются научными и инженерными сотрудниками компании VMware. Некоторое время назад этот проект переехал на портал VMware Labs, посвященный различного рода разработкам, облегчающим пользователям работу с продуктами в сфере виртуализации на платформах VMware. Также там есть и ресурсы, касающиеся VMware Academic Program.
Журнал VMTJ выходит два раза в год - зимой и летом, сейчас пока доступен только зимний номер этого года (69 страниц), но к концу лета должен подоспеть и следующий.
Статьи больше похожи на научные труды - это не посты о том, как какой-нибудь VMware NSX настраивать, а более глубокие и абстрактные исследования:
FlashStream: A Multitiered Storage Architecture in Data Centers for Adaptive HTTP Streaming
Reducing Cache-Associated Context-Switch Performance Penalty Using Elastic Time Slicing
The Role of Social Graph in Content Discovery Within Enterprise Social Networking
NoETL: ETL Code Generation for a Dimensional-Data Warehouse
A Framework for Secure Offline Authentication and Key Exchange Between Mobile Devices
Just-in-Time Desktops and the Evolution of VDI
Connectivity and Collaboration in VMware vCloud Suite
Directions in Mobile Enterprise Connectivity
В конце каждой статьи идет внушительный список использованной литературы. Всего с 2012 года было выпущено 6 неморов журнала VMTJ. Вот ссылки на предыдущие выпуски:
Совсем недавно компания StarWind Software, производитель средства номер 1 для создания отказоустойчивых программных хранилищ под виртуальные машины VMware и Microsoft - Virtual SAN, выпустила интересный документ по его бесплатному изданию - "StarWind Virtual SAN Free Getting Started".
Напомним, что полностью бесплатный продукт StarWind Virtual SAN Free позволяет превратить два новых или имеющихся у вас сервера в отказоустойчивый кластер хранения (с полностью дублированными зеркалированными узлами), который может служить для:
размещения виртуальных машин Microsoft Hyper-V (NFS/SMB3)
размещения виртуальных машин VMware vSphere (NFS)
размещения баз данных MS SQL Server (SMB3)
создания отказоустойчивого файлового сервера (SMB3/NFS)
Кстати, StarWind Virtual SAN Free - единственное решение, которое позволяет создавать HA-кластер из двух узлов неограниченной емкости абсолютно бесплатно. Более подробно об отличиях бесплатной и коммерческой версий продукта можно почитать вот в этом документе.
Таги: StarWind, Virtual SAN, Whitepaper, Storage, HA, Бесплатно, VMachines
Практически все администраторы виртуальных инфраструктур обеспокоены проблемой ее производительности в тех или иных условиях. На днях компания VMware обновила свое основное руководство по производительности платформы виртуализации номер один на рынке - Performance Best Practices for VMware vSphere 6.0.
Это не просто очередной whitepaper - это настоящая книга о производительности, на почти 100 страницах которой можно найти не только теоретические советы, но и вполне практичные настройки и конфигурации среды VMware vSphere. К каждому объясняемому параметру заботливо описаны рекомендуемые значения. В общем, Must Read.
Цель документа - дать понятие о методике сбора данных об ИТ-окружении, сайзинге, планировании архитектуры и внедрении VMware Mirage в инфраструктуру предприятия. Напомним, что сам Horizon Mirage предназначен для управления образами виртуальных и физических ПК на уровне слоев ОС, приложений и данных (это нужно для обновлений компонентов, бэкапа и восстановления, а также миграции ОС в корпоративной инфраструктуре).
Пояснения к работе схемы:
Каждый конечный ПК (виртуальный или физический) содержит установленный клиент Mirage, которые забирает слои (ОС, приложения, данные) с серверов Mirage (или кластера этих серверов).
Администраторы определяют расписание и проводят обновления этих слоев.
При изменении слоя на конечном ПК происходит синхронизация этих изменений в сторону датацентра, чтобы обе копии окружений были одинаковыми (этот процесс может инициировать как пользователь, так и администратор датацентра).
Если подумываете о внедрении Horizon Mirage, то документ, конечно же, нужно обязательно прочитать.
Это даже не совсем документ, а маленькая книга о том, как можно построить инфраструктуру доступа пользователей к виртуальным приложениям и ПК Citrix, размещенных частично или полностью в облаке Amazon EC2, с использованием технологии CloudFormation. Кстати, виртуальные ПК в Citrix XenDesktop можно создавать сразу в облаке с помощью Citrix Studio (технология и процесс подробно описаны тут).
Так вот, первый рассматриваемый в документе сценарий - это гибридная инсталляция, когда большинство сервисов компании работает on-premise (то есть, на собственной площадке), а инфраструктура Amazon используется для масштабирования сервисов, при пиковых нагрузках, а также как резервная инфраструктура в случае сбоя основной площадки. Ключевым компонентом здесь выступает NetScaler CloudBridge Connector, который создает оптимизированный для инфраструктур XenApp и XenDesktop VPN-туннель, а также обслуживает AWS availability zones (независимые зоны облачной инфраструктуры):
Второй вариант развертывания инфраструктуры Citrix XenApp и XenDesktop - это 100%-е использование облачных ресурсов Amazon для компаний, которым не требуется собственная инфраструктура (например, зачем турфирме свои серверы?). Здесь также ключевую роль играет NetScaler CloudBridge Connector, который обслуживает VPN. Все то же самое, но без своего оборудования (но нужен web-фронтэнд и cloud-совместимые приложения):
Доступ пользователей к своим приложениям происходит полностью через веб-клиенты, а администратор (скорее всего, приходящий) обслуживает инфраструктуру Citrix и зоны доступности на стороне сервис-провайдера удаленно через защищенный канал.
На самом деле, за такими штуками будущее, поэтому очень рекомендую этот документ.
Все вы, конечно же, знаете решение StarWind Virtual SAN, являющееся продуктом номер 1 на рынке для создания программных хранилищ под виртуализацию VMware и Microsoft.
Поэтому вам будет приятно узнать, что компания StarWind открыла ресурс, где в одном интерфейсе собраны открытые документы, записи вебинаров и прочее, касающееся Virtual SAN. Портал называется StarWind Resource Library:
Сейчас на этом сайте доступны следующие виды ресурсов:
Открытые документы (White Papers)
Технические документы и руководства (Technical Papers)
Записи вебинаров и обучающие видео
Истории успеха
Презентации по продукту
Также доступны и материалы на русском языке (для этого нужно поставить фильтр языка в левой колонке внизу):
Если вкратце, то компоненты vCenter предлагается защищать с помощью следующих решений:
1. Кластер высокой доступности VMware HA и сервис слежения за vCenter - Watchdog.
Сервис HA автоматически перезапускает виртуальную машину с vCenter отказавшего сервера на другом хосте кластера, а сервис Watchdog (он есть как на обычном vCenter, так и на vCenter Server Appliance) следит за тем, чтобы основная служба vCenter работала и отвечала, и запускает/перезапускает ее в случае сбоя.
2. Защита средствами VMware Fault Tolerance.
Теперь технология VMware FT в VMware vSphere 6.0 позволяет защищать ВМ с несколькими vCPU, поэтому данный способ теперь подходит для обеспечения непрерывной доступности сервисов vCenter и мгновенного восстановления в случае сбоя оборудования основного хоста ESXi.
Компания VMware предоставляет специализированный API, который могут использовать партнеры для создания решений, защищающих приложения в гостевой ОС, в частности, сервис vCenter. Одно из таких приложений - Symantec ApplicationHA. Оно полностью поддерживает vCenter, имеет специализированного агента и перезапускает нужные службы в случае сбоя или зависания сервиса.
4. Средства кластеризации на уровне гостевой ОС (с кворумным диском).
Это один из древнейших подходов к защите сервисов vCenter. О нем мы писали еще вот тут.
Для организации данного типа защиты потребуется основная и резервная ВМ, которые лучше разместить на разных хостах vCenter. С помощью кластера Windows Server Failover Clustering (WSFC) организуется кворумный диск, общий для виртуальных машин, на котором размещены данные vCenter. В случае сбоя происходит переключение на резервную ВМ, которая продолжает работу с общим диском. Этот метод полностью поддерживается с vCenter 6.0:
Кстати, в документе есть пошаговое руководство по настройке кластера WSFC для кластеризации vCenter 6.0 (не забудьте потом, где его искать).
Ну и в заключение, сводная таблица по функциям и преимуществам приведенных методов:
Далее идет описание средств высокой доступности в Enterprise-инфраструктуре с несколькими серверами vCenter, где компоненты PSC (Platform Services Controller) и vCenter разнесены по разным серверам. Схема с использованием балансировщика:
Обратите внимание, что для PSC отказоустойчивость уже встроена - они реплицируют данные между собой.
Та же схема, но с кластеризованными серверами vCenter средствами технологии WSFC:
Использование географически распределенных датацентров и сервисов vCenter в них в едином домене доступа SSO (Single Sign-On) за счет технологии Enhanced Linked Mode (каждый сайт независим):
То же самое, но со схемой отказоустойчивости на уровне каждой из площадок:
Ну и напоследок 2 дополнительных совета:
1. Используйте Network Teaming для адаптеров vCenter (физических или виртуальных) в режиме отказоустойчивости, подключенные к дублирующим друг друга сетям.
2. Используйте Anti-affinity rules кластера HA/DRS, чтобы основная и резервная машина с vCenter не оказались на одном хосте VMware ESXi.
Да, и не забывайте о резервном копировании и репликации виртуальной машины с vCenter. Сделать это можно либо средствами Veeam Backup and Replication 8, либо с помощью VMware vSphere Replication/VMware vSphere Data Protection.
Не так давно мы писали о том, что компания StarWind, производящая продукт для создания отказоустойчивых хранилищ Virtual SAN, выпустила документ о технологии VAAI, которая позволяет передать часть операций по работе с хранилищем на сторону дискового массива.
Компания StarWind, производитель лучшего средства для создания программных отказоустойчивых хранилищ Virtual SAN, выпустила два интересных документа на тему поддержки технологий
Второй документ - StarWind Virtual SAN ODX (Off-loaded Data Transfer) Configuration and Performance Tuning Guide - расскажет о том, как можно узнать включена ли поддержка ODX со стороны гипервизора Microsoft Hyper-V. Так же как и VAAI у VMware, технология ODX у Microsoft позволяет передать часть операций гипервизора с хранилищем на сторону дискового массива, что существенно повышает производительность ВМ.
Таги: StarWind, Whitepaper, VAAI, ODX, VMware, Microsoft
RSS
